home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Grab Bag
/
Shareware Grab Bag.iso
/
081
/
sirius50.arc
/
SIR050D.ARC
/
SIR_050.DOC
< prev
next >
Wrap
Text File
|
1987-07-14
|
32KB
|
739 lines
7/13/87
################################
# #
# What's new in Sirius v0.50 #
# #
################################
I. Logical expressions
II. Message groups
III. Scripts
IV. Outside now: Using YOUR text editor
V. Validation/repair
VI. Disk management
VII. Memory management
VIII. Keyboard interrupts
IX. Miscellany
X. Bug zaps
XI. Distribution
XII. Credits
XIII. Caveat
#######
# I. # Logical expressions
#######
Boolean and string functions are now available, and there are some new
integer functions as well. All of these functions are not only
available for use with IF tests and WHILE loops, but now also in
defining logical message groups (see section II below).
Operators
~~~~~~~~~
The special characters (<, <=, ...) previously used to represent
expression operators have been replaced by two- or three-letter codes:
NOT : logical NOT
AND : logical AND \ ANDs and ORs may not be mixed
OR : logical inclusive OR / in the same expression
EQ, NE : EQuals, is Not Equal to
LT, LE : is Less Than, is Less than or Equal to
GT, GE : is Greater Than, is Greater than or Equal to
Four operators have been added to facilitate string operations:
IN, NI : is contained IN, is Not contained In
CO, NC : COntains, does Not Contain
Functions
~~~~~~~~~
Sirius functions have Boolean (TRUE/FALSE), integer, or string values:
Boolean functions
~~~~~~~~~~~~~~~~~
Msg flags: @Private @Xpress @Received @Sent
@FileAttach @InTransit @Orphan @KillSent
@Local @Hold @FileReq
@ReceiptReq @AuditReq @UpdateReq
Other: @FromYou message is From or To anything matching
@ToYou / your main-menu "You" string(s)
@NoBody -- message file size <= 191
@ReadOnly -- message file cannot be altered or
(re)moved
Integer functions
~~~~~~~~~~~~~~~~~
@DaysHere -- number of days msg has been on this system
(as recorded in header bytes 180-183)
@DaysOld -- number of days since msg was authored
(as recorded in header bytes 176-179)
@FileSize -- number of bytes in msg file
@HighMsg# \
@LowMsg# \
@Msg# > (in current msg area)
@MsgCount /
@Zenith /
@NetFrom @NetTo @NodeFrom @NodeTo
String functions (case-INsensitive)
~~~~~~~~~~~~~~~~
@From = msg file bytes 1- 35
@To = " " " 37- 71
@Subject = " " " 73-143
@Header = " " " 1-190
@Body = " " " 191+
@Msg = the entire msg
@Keyin -- whatever was last keyed in response to
a Sirius "In" command (initially null)
Examples
~~~~~~~~
@DaysHere GT 14 AND @InTransit
@From EQ 'Robot' AND @FileAttach
@From NE 'Someone I prefer to ignore'
@Local AND NOT @Sent
@Msg CO 'YooHoo' OR @Msg CO '2U2'
@Msg NC 'FLAME ON'
@MsgCount GT 200
@NetTo EQ 150 AND @NodeTo LE 1
@ReceiptReq AND NOT @Local AND NOT @InTransit
@ToYou AND NOT @Received
@ToYou OR @FromYou
Note also that because the set of relational operators is closed with
respect to negation, subexpression parenthesization is not required.
Got that?
Performance issues
~~~~~~~~~~~~~~~~~~
In expressions, use the least disk-intensive functions first.
For example, several functions require no disk activity at all and
are best placed first in Sirius expressions:
Boolean functions @NoBody and @ReadOnly,
integer functions @FileSize, @HighMsg#, @LowMsg#, @Msg#, @MsgCount,
and @Zenith, and
string function @Keyin
Similarly but at the other end of the spectrum, if your compound
expression contains string searches of the message body (functions @Body
or @Msg), put such subexpressions last.
Run the script SLOWFAST.SIR to see these principles in action.
While We're At It
~~~~~~~~~~~~~~~~~
By using these functions within If's and While's, you can automatically
identify messages from whomever or whatever you choose, and do whatever
with them. Thus programs like KILLRDOG become just one way of running
Sirius.
(Zenith
! (While (@Msg# LE @HighMsg# AND 'you-name-it' IN @Subject))
Copy (Flat file ('UNAMEIT.SAV'))
Next
! (End))
The above script will copy all messages not yet read on a given subject
in the current message area to ASCII text file UNAMEIT.SAV.
(Zenith
! (While (@Msg# LE @HighMsg# AND @To CO 'Klahn'))
Copy (Printer 'n')
Next
! (End))
This script prints all new messages in the current area which contain
'Klahn' anywhere in the "To:" field, without page ejects.
########
# II. # Message groups
########
The Group subsystem has been generalized to use all of the logical
expression functionality discussed above. The old case-sensitive
message flag toggles are history.
If you're familiar with the "SET FILTER TO" command in Ashton-Tate's
dBASE III, then you are also on familiar ground here. With a logical
group definition active, your message base will behave PRIMARILY as if
only contains those messages which satisfy the active group definition.
(But see "Absolute and relative positioning with groups active" below.)
Defining a logical group
~~~~~~~~~~~~~~~~~~~~~~~~
Select "Group" from the main menu, then "Define" from the group menu,
and select a letter from A to Z as the name of the logical group you
want to define, and you'll be into the general expression parser.
To delete a previous definition, say for group "D", then simply select
"Group Define D" and hit enter, and Sirius will tell you that it is
"Discarding group D definition ...".
The group you define automatically becomes the active group. If you are
defining a group before you are ready to use it, then press "GU" to Use
a different Group; use a group not yet explicitly defined if you want to
disable all "filtering".
You'll probably want to have a printout of the full Sirius function list
handy as you are learning to use logical expressions effectively. The
listing in section I above is duplicated in file SIREXPR.HLP.
Member memory
~~~~~~~~~~~~~
When scanning messages, Sirius "remembers" which messages do and don't
belong to the current group, and "keeps handy" as many of those as the
"header buffer" memory you've allocated will allow.
If you Use a different group and subsequently Use the former one again,
Sirius will still remember the previously scanned messages which belong
to it IF they have NOT been tested for membership in the more recently
used group.
Thus if you use Sirius groups often (you will), you'll want to allocate
as many "header buffers" in SIRIUS.CFG as your system can handle while
still avoiding the "Sirius has almost run out of memory" message. See
"Memory Management" section VII below, and have fun compromising.
What's happening?
~~~~~~~~~~~~~~~~~
You will probably have many occasions to define groups which have few,
if any, members in your message base. Sirius lets you know it's doing
something during message searches (via Next, Prev, Group Headers, or
Group List) by displaying the current message NUMBER at the beginning of
the current screen line whenever a message is examined which does NOT
belong to the current group. Thus you always know "where Sirius is" in
the message base, and "how hard it's working".
Conversely, if Sirius already knows that a given message is NOT a member
of the current group, its number will NOT be displayed.
Zeroing in
~~~~~~~~~~
After defining or selecting a logical group, consider getting a Group
Headers listing first, and THEN viewing messages one by one using your
ENTER key. If you've defined enough header buffers to hold the entire
group, you'll like this approach.
Absolute and relative positioning with groups active
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Next" and "Prev" are the only RELATIVE positioning commands; all the
others (Back, High, Low, Zenith, +, -, #) are ABSOLUTE. "Next" and
"Prev" will always position you at the next or previous message IN the
current group; the ABSOLUTE message positioning commands disregard group
definitions.
Be particularly careful of this distinction when writing scripts which
use group definitions. As an example, "0" then "Next" is the proper way
to position to the lowest message in the current area which is also a
member of the current group; using "Low" in this context will cause
problems for you. There is currently no RELATIVE "Low" or "High"
command.
Sirius message positioning commands have been structured in this manner
because it is important for you to be able to work with messages NOT in
the current group. For example, when entering replies to messages in
the group "@ToYou", you should be able to re-examine and possibly doctor
your reply after having saved it.
Group definition examples
~~~~~~~~~~~~~~~~~~~~~~~~~
1) @Msg CO 'Telebit' OR @Msg CO 'blazer' OR @Msg CO 'half duplex'
Scan the COMM conference for news about just one modem. Perhaps
you'll also want to run a quick While loop to copy all matching
messages to flat file TELEBIT.NWS.
2) @NoBody AND @FileAttach AND NOT @Local
Weed out all those bodiless file-attach messages.
3) @Private AND @Received AND NOT @ToYou
You may want to run a quick While loop using the Kill command to get
rid of all these in a hurry. Or you may want to use Group Headers
to take a quick look at them first.
4) @ReadOnly
Suppose you are running SEAdog 4.00 in your other DoubleDOS
partition, and you want to see the exact messages which have been
packetized for mailing. Use this simple group definition in your
netmail area and exercise the Group Headers command for a quick
summary.
5) @Body CO 'FLAME ON'
So you're extremely argumentative, but you don't have access to Ken
Shackelford's FLAMES echo? Use this group definition to pick out
the "hottest topics" from everything you can reach. Just start
tapping your ENTER key and SKIP OVER all that other trash without a
look. You can still change your mind and go back and read it all
later.
6) @Msg NC 'likes EVERYTHING!"
Clearly no discrimination at all. Use this with the Move command to
pull all matching messages into another echo. (That's a JOKE,
folks!)
One more example
~~~~~~~~~~~~~~~~
Try using a group to modify script PRINTNEW.SIR so that it prints only
the overnight mail you're SURE you want to read over breakfast the next
morning.
Miscellaneous notes
~~~~~~~~~~~~~~~~~~~
* "Group Headers" and "Group List" should be familiar to you; they are the
former "View Headers" and "View List", respectively. These two commands
were repositioned because they really are GROUP-related ACTIVE commands,
whereas all VIEW commands are intended to be SETTINGS only.
* Consider putting your favorite group definitions into startup script
file SIRIUS.SIR to avoid rekeying.
#########
# III. # Scripts
#########
Call your own plays
~~~~~~~~~~~~~~~~~~~
The Play command now allows Sirius scripts to invoke one another, thus
making more modular Sirius "programming" possible. As an example, see
enclosed script INTRO.SIR, which calls other Sirius scripts
("SUBscripts"?) to perform various functions designed to introduce the
new user to the Sirius environment.
A whole new look
~~~~~~~~~~~~~~~~
The In and Out commands, and the new Wait command, now allow you to
interact with the user via menus and prompts that YOU create.
An example of the In command's new syntax is
In ('Press Q to quit, or any other key to continue ...' 1)
Here the string "Press Q to quit, or any other key to continue ..."
will be displayed on a new line and the cursor will be positioned at the
end of this prompt waiting for a MAXIMUM of one input keystroke.
Likewise,
In ('Type the name of the command you want help with:' 12)
will accept input keystrokes until either ENTER is pressed or the input
string is twelve characters long, whichever occurs first.
The most recent user input in response to an In (...) command is stored
in the string function @Keyin, which may be used anywhere other
string functions are allowed. @Keyin is equated to the null string ('')
at the start of each Sirius session.
The Out command, when used without text strings, i.e., as "Out ()" in
script form or as "O" then ENTER from the keyboard, will simply clear
the screen, IF screen clearing has been enabled in SIRIUS.CFG.
The new Wait commands takes two forms. "Wait (Any key)" or "WA"
displays "Press any key to continue ..." and suspends Sirius execution
until that request is satisfied. "Wait (5)" or "W5" will suspend
Sirius execution for five seconds, or until the ESC key is pressed,
whichever occurs first.
Taken together, these three commands allow the Sirius sysop to give his
or her message base a whole new look. Future Sirius tie-ins to "user
base" and "last user" files should bring this facility into its own.
See script INTRO.SIR for a good example of how to build a menu script in
Sirius.
One note of caution: once invoked, all Sirius scripts remain memory
resident for the duration of the Sirius session (this will change in
future versions), so beware of going overboard with this facility when
memory is limited.
Fast forward
~~~~~~~~~~~~
Script playback has been enhanced with remote users in mind. "Fast"
playback mode eliminates a LOT of the less important console I/O.
Scripts invoked from the DOS command line automatically run in fast
mode.
Try out one or more of the distributed scripts in both "fast" and "slow"
modes to see the sometimes dramatic difference in performance, locally
as well as remotely.
-- More?
~~~~~~~~
If you don't want to hit "n" in response to the above prompt, then now's
the time to branch off from this DOC file to SCRIPTS.DOC (in archive
SIR050S.ARC) for a quick overview of all the scripts we've given you to
play and learn from. ("Tag" this location first so you can readily come
"Back" to it ...)
Keeping things going
~~~~~~~~~~~~~~~~~~~~
Sirius scripts which are to run unattended need a few "extras":
* View (Continuous)
All "More <Y,n>?" prompts are eliminated, ensuring that an unattended
script will not pause, awaiting input from the console (unless you ask
for it with the In command).
* Quit (If error? ('Y'))
Use this command to ensure that error conditions will cause a clean exit
from the script.
* Group (Define ('A'))
Defining a group with no expression deletes the group definition. As
long as this "null" definition is active, ALL messages in the current
message area are considered to be members of the current group. Call
this the "modular" approach. The next time you change startup script
SIRIUS.SIR just before bedtime, you are less likely to find your system
with a hangover when you awaken.
########
# IV. # Outside now: Using YOUR text editor
########
In the Sirius 0.50 SIRIUS.CFG file there is a "Jump directory" parameter
which allows you to specify any specific subdirectory to Jump to, either
from the main menu, or via Doctor Body Jump. If not specified, the
default is the current directory. Once there, you can do what you like.
Sirius will nicely take you back to your current directory (or even
drive) when you EXIT back to Sirius.
There is also a line called "Outside editor" which allows you to specify
the editor you want to use with the above commands. Note that Sirius
assumes it can invoke the editor by using whatever command you put on
that config line and appending the drive:path\SIRIUS.TXT. If your
editor won't work that way, this won't work. (You may be surprised, it
may work even if undocumented.) If you don't specify an editor, Sirius
won't let you go outside.
* Outside soft returns ASIS NONE HARD
Your editor may or may not take well to the way FidoNet messages are
normally formatted. Fidonet messages have SOFT returns in them, so that
they can be rewrapped if need be. While Personal Editor likes this,
most don't. If yours does, use ASIS on this config line.
If your editor likes to do its own formatting period, and can survive
lines as long as paragraphs (may be thousands of chars) then use NONE.
An example of this kind of editor would be XyWrite.
Almost ANY editor will do well with HARD, which converts soft returns to
hard, but then FidoNet boards (OPUS and SEAdog too) will not be able to
rewrap the results. Note, however, the Sirius Body Doctor provides a
method for rewrapping message text. Thus, if you must use HARD returns
with your outside editor (PC-Write is an example), then when you exit
the editor and return to Sirius, you may subsequently rewrap the text
using the appropriate body doctor command and transform the hard returns
back to soft returns.
Doctor Body Outside creates the file SIRIUS.TXT in the Sirius directory.
SIRIUS.TXT contains the body of the current message. The SIRIUS.TXT
file is deleted upon return to Sirius.
As always, both of these new commands can be scripted, so that all sorts
of textual manipulations can be automated with the proper editor.
Consider these last as "words to the wise."
#######
# V. # Validation/repair
#######
Sirius will attempt to repair messages that it finds flawed in some way
(as is not unusual in EchoMail conferences). The original message is
renamed for later inspection, and the repaired message is marked with a
line at the top of the message body indicating what portions of the
message Sirius found to be improperly constructed. This errata line
also indicates the name of the original message file, the system
"noticing" the error(s), and the system, if any, from which the message
was received. For example:
* Err: Subject (file 02-Jul13.1 on 150/1, from 107/312)
The naming convention for bad messages has been changed from #.BAD (in
Sirius version0.47) to AA-MmmDD.#, where
AA is the area number, right-justified and zero-filled,
Mmm is the alpha month,
DD is the day of the month, and
# is a counting number.
Thus the first bad message encountered on July 13th, in the Sirius echo
(and it would be a first for sure ... apart from my local testing) would
be renamed to 02-Jul13.1 here on 150/1.
What this accomplishes: now all bad messages have unique names, so that
they can be collected into a single subdirectory if you so desire.
These COULD be made file-requestable, or ... a clever script generated
via a DOS batch file COULD automatically file-attach offending messages
back to their source, as Sirius 0.47 has allowed you to do more directly
(and we all know how well THAT was received!).
Time out of mind
~~~~~~~~~~~~~~~~
Through the use of "floating match logic", Sirius is always able to
produce a valid date, time, AND day of week, no matter how the date is
stored inside the message header. For example, if there is no
day-of-the-month, Sirius will still find and use the month itself.
Sirius also (1) understands, (2) generates if not already present, and
(3) validates if already present the internal message arrival/creation
dates generated by Opus (see the description for the @DaysHere function
above).
If you are not running Opus but would still like to delete messages
based on how long they've been on YOUR system, then (1) a quick "Group
Headers" pass over newly received messages is all you need to fix the
arrival dates, and (2) a while loop using the @DaysHere function will do
the rest. Exercise left to the reader.
(And YES, fellow techies, messages HAVE come through here with FF hex in
byte twenty of the traditional date/time field AND with garbage in bytes
176-183!)
########
# VI. # Disk management
########
* "While" loops are FASTER now, by quite a bit! More specifically, the
greatest relative improvements will occur in scripts which write or
modify disk files. For example, on my system, SIRECHO.SIR (which
archives the SIRIUS conference, a la Wes Cowley's Pixie) is now about
five times faster than with Sirius version 0.47.
* When you doctor a message, the changes are now permanent. The *.BAK
files generated by earlier versions of Sirius are no longer created.
(Deafening roar of applause.)
* Sirius now has "real-time" message overwrite protection: copying/moving/
entering/replying will NEVER overwrite existing messages, such as those
generated "in the other DoubleDOS partition".
High-end messages created AFTER your Sirius session began CAN be "found"
without quitting Sirius and reloading. Exercise left to the reader.
#########
# VII. # Memory management
#########
Out-of-memory conditions are MUCH less likely to occur in 0.50.
Nevertheless, Sirius now warns you when it is ALMOST out of memory.
Almost 5K more memory is required on SOME systems at startup than with
version 0.47, but MUCH LESS memory is consumed AFTER startup.
Sirius now uses CIRCULAR HEADER BUFFER logic. The number of header
buffers to allocate is specified in configuration file SIRIUS.CFG. As
new message headers are loaded, older headers are overwritten; there are
never more message headers than the maximum configured in memory at any
given time.
Rule of thumb: The larger you can make "Headers Buffered" (in
SIRIUS.CFG) without running out of memory, either within Sirius or
outside of it, the better.
Sirius wants 180 bytes for each buffer, of which there can be as few as
4 or as many as 255. If "headers buffered" is not specified in
SIRIUS.CFG, 25 buffers are allocated.
All header buffers are allocated at STARTUP. Thus if you are having
trouble bringing Sirius up at all, or if you are "running out of memory"
more often than you'd like, consider reducing "headers buffered".
Conversely, if you have yet to run out of memory during a Sirius
session, and you are happy with the amount of memory available when you
jump to DOS, then try increasing "headers buffered" to gain speed,
ESPECIALLY with logical group operations (as explained in section II
above). The more buffers you have, the faster Sirius is at RE-viewing
messages.
##########
# VIII. # Keyboard interrupts
##########
Sirius gives you a number of ways to interrupt operations in progress:
Key Effects ...
~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SPACE * Skips remainder of current message, both its display and
its possible output to a flat file.
* Terminates Group Headers, Group List, and Area lists.
CR * Skips remainder of current message as SPACE does, A-N-D
moves to the adjacent message in the current direction of
travel AND in the current group.
* Terminates Group Headers, Group List, and Area lists.
ESC * Terminates almost everything.
* Does NOT terminate display/output of the current message.
Thus scripts such as SIRECHO.LST can be interrupted and
resumed without any adverse effect on flat file output.
C * Continuous viewing \ as of the next
S * Viewing a screenful at a time / expression evaluation
T * Force next expression evaluation to be TRUE
F * Force next expression evaluation to be FALSE
W * Wait while depressed, resume one second after release
Note that not all Sirius activity is interruptable. If Sirius were
ALWAYS looking for keystrokes, it would run significantly slower.
Experiment to see what works best for you.
########
# IX. # Miscellany
########
Message creation/display
~~~~~~~~~~~~~~~~~~~~~~~~
* Origin lines are generated if specified in SIRIUS.CFG, OR in AREAS.BBS
when Sirius is building SIRIUS.ART.
* Both origin lines and VISIBLE Sirius tear lines are generated only in
areas having AKA's (Area Known as); this INCLUDES the netmail area.
* All reply quoting is now indented at least one space, so that subsequent
editing with SEAdog's MAIL.EXE will not destroy the prefixing alignment.
Thus, for example, typing just ">" yields a prefix of " > " (the only
prefix SEAdog understands).
* "!" has been disallowed as a reply/quote prefix terminator, so that an
interjection in a one-line paragraph will not be interpreted as a
prefix.
* A message's net/node TO or FROM is displayed whenever it differs from
your primary net/node identity.
* A reply's net/node TO is ALWAYS set equal to the replied-to message's
net/node FROM; this and the previous feature make it much easier to copy
and move messages into and out of "netmail" areas.
Message movement
~~~~~~~~~~~~~~~~
* Both the Move and Copy commands now have a "Stamped" option. This
records the name, or number if no name exists, of the area the message
came from, along with the the current date and time, as the first line
of the message body.
Inter-system detail
~~~~~~~~~~~~~~~~~~~
* You must specify your net/node identity in SIRIUS.CFG; this is of
particular importance now that Opus 1.00 no longer uses a MAIL.SYS file.
* The Doctor (Netmail (...)) command set now allows you to alter the LOCAL
flag in addition to all the others.
Tables
~~~~~~
* Sirius now supports one hundred message areas.
* On the area table and defined group displays, an asterisk marks the
active (current) entry.
Appearances
~~~~~~~~~~~
* "Not yet implemented" features and messages have been removed. What you
now see is what you get.
#######
# X. # Bug zaps
#######
* Sirius area table SIRIUS.ART is built (if missing) using A-L-L
SYSTEM??.BBS files in the startup directory WHETHER OR NOT it finds
a match on OPUS*.* there.
* SIRIUS.ART once again picks up DIR.BBS area descriptions if present.
This was broken in 0.47 only.
* Sirius scripts recorded in lower case would not play back properly in
0.47. Fixed with a vengeance. Interpretatio of THAT comment left to
the reader.
* When recording While loops to script files, all iterations but the first
are at last suppressed.
########
# XI. # Distribution
########
Sirius 0.50 should only be distributed with this packaging:
SIR050D.ARC 59KB -- Documentation (required)
SIR050E.ARC 145KB -- Executables "
SIR050S.ARC 17KB -- Scripts "
SIR050M.ARC ~ 21KB -- Menu customizer (optional)
If you haven't read file CAREWARE.DOC, please do so now. Basically, if
you use Sirius, I want to know about it.
#########
# XII. # Credits
#########
I owe the Sirius Beta Group a debt of gratitude. Pat McDonald, David
Page, and Bob Davis have contributed time, ideas, many bug reports, some
of the above documentation and enclosed scripts, and HARD WORK in
general.
Thanks, Pat, for your many fine ideas, such as the @Keyin string
function), your Opus Gazette/FidoNews review, and your tirelessness in
general. Thanks, David, for your outside editor ideas and
documentation. Thanks, Bob, for your commercial perspective; there are
hardly any "not yet implemented" messages left!
And thanks to ALL who have participated in AREA:SIRIUS or who have sent
ANYTHING to me here at 150/1, be they bug reports, ideas, requests,
HELLOBOB.SIR-generated registration messages, or simply questions. They
all help.
##########
# XIII. # Caveat
##########
The leading "0" in the Sirius version number tells you that
(1) Sirius documentation is still sketchy, and
(2) major structural changes MAY be made in future versions.
The leading "0" will become a "1" when
(1) the documentation is truly of professional quality, and
(2) overall data structures have stabilized.
###
